The use of photohosting websites that allow users to upload digital images to a server on the Web for storage and display are becoming increasingly popular. Once a set of images have been uploaded to a photohosting site, the photohosting site typically displays the images in the form of an online photo album.
There are many reasons why it is preferable for photohosting sites to generate multiple versions of each uploaded image that may differ from the original in terms of resolution, file type, and style. For example, much smaller versions of the original images, referred to as thumbnails, are usually created for display in the online photo albums in order to increase the speed at which the photo albums may be displayed in the user's Web browser.
Given the storage requirements for storing many different versions of each image, many photohosting websites create the images dynamically, i.e., on demand, and store or cache those versions of the images that are requested most often.
The photohosting site has a server that is programmed to receive a request for a particular version of an image via standard Web protocols. The code on the server determines if the image has been previously generated, and if not generates the requested version image, and then returns the generated version of the image to the requester.
FIG. 1 is a block diagram illustrating a conventional photohosting system that can serve an image in multiple formats. The system 10 comprises a photohosting site server 12 that responds to requests made from a user's Web browser 14. The server 12 typically includes an image database 16 for storing original uploaded images, and a file system 18 for storing folders and files, including image files. Programs that implement the functionality of the server 12 may include a servlet 22 and an image processing library 20. The servlet 22 may typically include a URL parser 24, a file locator 26, and an image generator 28, which function as follows.
In operation, the Web browser 14 displays a web page 30 from the server 12 that may include a link 32 to the original image and a link 34 to a modified version of the original image. If the user clicks the link 32 to the original image, the Web browser 14 sends a URL (uniform resource locator) including the original image ID to the server 12, which will then retrieve the original image from the image database 16 or the file system 18 and return the image to the Web browser 14 for display.
If the user clicks the link 34 to modified image, then the Web browser 14 sends a URL with the image ID and a list of parameters (e.g., resolution, format, and style) specifying how the original image is to be modified. The servlet 22 on the server 12 receives the URL and passes it to the URL parser 24. The URL parser 24 parses the URL and strips the modification parameters from the URL. Using the image ID, the file locator 26 determines the location of the original image, e.g., in the image database 16 or somewhere in the file system 18. The image generator 28 determines if the original image has already been modified as requested by the URL and whether the modified image is stored in the file system 18. If the modified image is present in the file system 18, the modified image is returned to the Web browser 14.
If the modified image is not present in the file system 18, then code in the image generator 28 generates the modified image by using the URL parameters input from the URL parser 24 in calls to the image processing library 20. The image processing library 20 then performs the requested changes on the original image to create the modified image. The modified image is then stored in the file system 18.
The following illustrates a portion of code in the image generator 28 responsible for interpreting the URL parameters. For purposes of example, assume that the system receives the following exemplary URL:
http://serveraddress?file=AxD209&style=B.
As those with ordinary skill in the art will readily appreciate, the portion of code in the image generator 28 responsible for interpreting URL parameters may be hard coded as a common “switch” statement, or as a series of “If then” statements, as follows:
                |        switch (style) {                    case ‘A’;                            |                |                break;                                    case ‘B’;                            create new style (parameters);                break;                                    case ‘C’;                            |                |                break;                                    |            |                        }In this example, “style” is a parameter in the received URL above (style=B). Given the presence of this parameter, the switch statement is invoked and any image processing library 20 calls associated with the given “case” statement whose condition is true are invoked. In this example, since style=B from the URL, any image processing library 20 calls associated with the switch statement “case ‘B’” are invoked.        
Although the system 10 works well for its intended purpose, the system 10 requires an operator of the server 12 to write custom code for the image generator 28 that examines each URL parameter in order to make the image processing library calls. In order to add or change a parameter, the operator must open the source code, modify the source code, and then recompile the source code to create an executable object that can be executed by the server. This is not only a time-consuming process, but also requires software expertise.
Another disadvantage of the conventional system 10 is that if a URL is received having the same parameters as a previous URL, then the image generator 28 may consequently produce duplicate image formats and duplicate modified images. A further disadvantage of the conventional system 10 is that in signal processing, performing operations in a different order can produce different results. Therefore, when producing image formats, it is insufficient to only know that operations A and B, for example, were applied to an image; it is also necessary to know and what order the operations were performed.
Accordingly, there is a need for an improved method and system for serving multiple image formats in which different image formats may easily be added to the system. The method and system should not need to recompile source code when formats are added or modified, the method and system should reduce the chances that duplicate image formats will be created, and the method and system should preserve the order of operations involved in each of the image formats.